The system converts messages from upper-case-only folks to
lower-case, then does a simple capitalization algorithm. This is
lots easier on the eyes of those who actually read messages. This
feature does, however, trip up people who actually @emph{intended} a
message to be all upper-case.
If you include even one lower-case
character in a message, the conversion and capitalisation thing will
not be done, so a standard trick is to put a lower-case L (@samp{l}) in
place of a @samp{1} somewhere. I've seen people do this l0 times,
just to be sure! (Credit where credit is due -- we didn't
put this one in, it came with STadel, but was probably put in by
Hue, Jr. in Citadel-86, or even CrT in the original CP/M Citadel.)
@node <fnord>s, User timeouts, Uppercase elimination, Curious Feeps
@subsection <fnord>s
@cindex Fnords
@cindex Subliminal <fnord><vote Rhino> messages
Fnordadel is a somewhat whimsical piece of software. Some of
its features have been hacked in on the spur of the moment; others just
seemed to materialise. The authors' primary reason for working on the
software at all is just ``because it's neat''. So, we occasionally break
from ``serious hacken'' and put in bits of silliness or weirdness. The
<fnord> feature is one such bit.
<fnord> is a subliminal trigger word, and since @sc{bbs}es are
the ideal forum for perpetuating subliminal messages, we've
thoughtfully bound the @samp{P} key (at the room prompt level) to
the <fnord>s.
Simply put a file called @file{fnord.sys} in your @code{#sysdir}. It
@vindex sysdir
should contain a list of silly sayings, one per line, which will be chosen
from at random and spit at the user when he (always mistakenly) hits @samp{P}. The size of @file{fnord.sys} is practically unlimited, but it is all loaded
into @sc{RAM} when Fnordadel starts, so be very careful.
Anyway, say your @file{fnord.sys} has the following lines:
@example
send money
read my lips
no newt axes!
the Sysop's a babe
@end example
Depending on the state of some random bits inside the machine, a
user hitting @samp{P} might see
@example
<fnord><no newt axes!>
@end example
@noindent
and will suddenly begin to wonder whether Mr Bush ever said
anything about ``Taxes''. Or he might see
@example
<fnord><the Sysop's a babe>
@end example
@noindent
in which case you can expect a proposition in @code{Mail>}. Or, best of
all, he might see
@example
<fnord><send money>
@end example
@noindent
and, if you've thoughtfully put your mailing address in, say, a
help file (or perhaps in another <fnord>), the money will roll in.
Neat, huh?
To disable <fnord>s, if you don't like 'em, just get rid
of the @file{fnord.sys} file.
@node User timeouts, New user message viewing, <fnord>s, Curious Feeps
@subsection User timeouts
@cindex Idleness, user timeouts because of
@cindex Timeouts due to user idleness
@cindex User timeouts due to idleness
It's an annoying thing to have users monopolize your system
for large chunks of time, but it would be even more annoying if they
did so by spending long minutes idly sitting at a command prompt
somewhere. To prevent this, Fnordadel has a timeout feature that
it inherited from STadel: if a user's session is idle (i.e. no screen
or keyboard activity) for 3 minutes or so, the system will print a
cutesy message and log him/her off. This timeout can also apply to
console users such as the Sysop, if you wish it. See the @code{sysopsleep}
@vindex sysopsleep
parameter in @file{ctdlcnfg.doc}.
@node New user message viewing
@subsection New user message viewing
@cindex New users, message reading by
Another annoying thing is having a new user call in (at 300
baud, too, wouldn't you know it!) and read every message in every room
on your system. Argh! Well, there is a @file{ctdlcnfg.sys} parameter called
@vindex newusermsgs
@code{newusermsgs} which lets you set how many messages the system will
think are new to each new user calling in. It defaults to @samp{50} if you
don't set it otherwise. If you set it to @samp{0}, all messages will be new.
This variable helps the user's first call to get him/her the gist of what's
being discussed, without swamping her/him with an overload of info, or
crippling your system with massive connect times. Of course, it
doesn't help on subsequent calls@dots{}
@node User configuration defaults
@subsection User configuration defaults
@cindex User configuration, defaults
@cindex Defaults for user configuration
We had a request to allow the Sysop to set default values for some of
the user configuration values that new users aren't asked about if
they claim not to be Citadel experts. To that end, there are currently
several @file{ctdlcnfg.sys} flags that you can diddle to give your novice users
the ``correct'' combination of features: @code{defshowtime}, @code{deflastold},
@code{deffloormode}, @code{defreadmore}, @code{defnumleft} and
@code{defautonew}. See
@vindex defshowtime
@vindex deflastold
@vindex deffloormode
@vindex defreadmore
@vindex defnumleft
@vindex defautonew
@file{ctdlcnfg.doc} for more.
@node Status line
@subsection Status line
@cindex Status line
@pindex citadel
@pindex +line (citadel)
One of the most popular additions orc made to STadel was the status line, an
inverse mode, non-scrolling line of user information placed at the bottom
of the console screen. It is activated by invoking @code{citadel} with
the @code{+line} option. This gets you at-a-glance information about an
online user, including user name, current room, time of login, current
time, and some flags.
@cindex Status line flags
The flags consist of @samp{R}, which indicates a Sysop console request is
pending (@pxref{Special keys}); @samp{T}, which indicates the current user
is a twit (@pxref{Special keys}, @pxref{Your Callers}); @samp{C}, which
indicates chat mode is currently enabled (@pxref{Sysop Special Functions});
and @samp{*}, which indicates that the user has an unanswered chat request
outstanding.
If the status line is not active, Fnordadel will display some information
about the user just before each room prompt as the user moves about the
system. This information is shown only on the console.
@node Rotating banners
@subsection Rotating banners
@cindex Rotating banners
@cindex Banners, rotating
We received several requests to implement @dfn{rotating banners}, something
Hue, Jr. recently put into his Citadel-86. Figuring we'd already blown any
possible reputation for seriousness, we figured ``what the heck'', and here
they are.
To use rotating banners on your system, create a number of files called
@file{banner.1}, @file{banner.2}, @file{banner.3}, etc. in your
@vindex helpdir
@code{#helpdir} directory. Leave the existing @file{banner.blb} file there.
Then define the @file{ctdlcnfg.sys} parameter
@vindex numbanners
@code{#numbanners} to be the number of banners you want to rotate through.
You can set the parameter
@vindex bannerblb
@code{#bannerblb} to @samp{1} if you want the system to display
@file{banner.blb} following the rotating banner it picks at random, or to
@samp{0} if the rotating banner files should stand alone.
@node File Locations, Multitasking and Fnordadel, Curious Feeps, Miscellaneous
@section File Locations
@cindex System files
@cindex Files, where they all live
The following is a more-or-less complete list of where Fnordadel
expects to find which files (or where you can find files that Fnordadel
deposits). Don't shoot us if we've missed one, though.
@table @code
@item #auditdir
@vindex auditdir
@table @file
@item calllog.sys
The call-log
@item filelog.sys
The user file transfer log
@item netlog.sys
The network activity log
@item debuglog.sys
The debugging log
@item chat.rec
Text from captured Chat sessions
@item sysop.msg
Where archived Sysop mail goes (if enabled)
@item callstat.sys
Useful statistics written by @code{callstat}
@pindex callstat
@item callbaud.sys
Supplementary useful statistics from @code{callstat}
@end table
@item #helpdir
@vindex helpdir
@table @code
@item *.hlp
Help files
@item *.mnu
Menus
@item *.blb
``Blurbs''
@end table
@item #holddir
@vindex holddir
@table @file
@item hold@var{nnnn}
Held message for user #@var{nnnn}
@end table
@item #msgdir
@vindex msgdir
@table @file
@item ctdlmsg.sys
The message base
@end table
@item #netdir
@vindex netdir
@table @file
@item ctdlnet.sys
The net-list
@item ctdlloop.zap
The loop-zapper database
@item ctdlpath.sys
Path alias definitions
@item dial_@var{n}.prg
External dialer programs
@item @var{n}.ml
Semi-temporary files for net-mail to node #@var{n}
@item @var{n}.nfs
Semi-temporary files for file sends/requests for node #@var{n}
@item @var{n}.fwd
Semi-temporary files for mail forwarding to node #@var{n}
@item @var{xxxxxxx}.dis
Discard message files
@end table
@item #roomdir
@vindex roomdir
@table @file
@item room@var{nnnn}.sys
The room files (where @var{nnnn} = 0000 to (@code{maxrooms} - 1))
@item room@var{nnnn}.inf
The optional room info files (where @var{nnnn} = 0000 to (@code{maxrooms} - 1))
@end table
@item #sysdir
@vindex sysdir
@table @file
@item citadel.lck
Lockfile used by @code{citadel} and many others; helps
prevent dangerous collisions when using doors or a
multi-tasking system.
@item ctdllog.sys
The user log
@item ctdlflr.sys
The floors file
@item ctdldoor.sys
Door definitions
@item ctdlarch.sys
Room archiving information
@item alias.sys
Shared room aliasing definitions
@item purge.sys
List of users to whom the purge feature will apply
@item restrict.sys
List of users to restrict login to
@item fnord.sys
Silly sayings for the @samp{P} key
@item calldata.sys
Cumulative data maintained by @code{callstat}
@pindex callstat
@item checkpt.sys
Checkpoint file for @code{configur}
@end table
@end table
In addition, a few files are expected to live in Fnordadel's home
directory (i.e., the directory in which Fnordadel is run). These are:
@table @file
@item ctdltabl.sys
The system tables file; needed by almost everything,
including @code{citadel}. Regenerated by @code{configur}.
@item crash
If there's been a crash and Fnordadel saw it coming,
this is where it puts a report.
@end table
@node Multitasking and Fnordadel, Fnordadel vs. STadel, File Locations, Miscellaneous
@section Multitasking and Fnordadel
@cindex Multitasking
Some time before orc ceased work on STadel, he made some modifications
to it to make it operate a little nicer in a multi-tasking environment on the
Atari ST. The multi-tasker he specifically tested was AMULTI, but MX2, MiNT
and Multi-GEM are three others we know of as of this writing. The first three
are public domain,
all four should be used only if you know what you're doing, and none of them
is guaranteed to work properly or reliably with Fnordadel, since we've
never done a lick of work to make sure Fnordadel will live properly with
them. However, it's on our list of things to do when we get time, so don't
hesitate to send reports of your experiences with Fnordadel and
multitasking. Any information we can get from out there will make us that much
better prepared to tackle any problems there may be.
@pindex citadel
@pindex +multi (citadel)
@cindex Background process, Fnordadel as a
To activate Fnordadel for use in a multi-tasking environment, as a background
process, invoke @code{citadel} with the option @samp{+multi}, and using
whatever mechanism your multitasker needs to indicate a background process.
(See the options section of @file{citadel.man}.) At this point in time, all
this option does is basically shut off Fnordadel's screen output so that the
display doesn't get messed up while you're doing other things, and make the
system ignore keyboard input from the console. All other activities continue
as normal, including networking.
@cindex Foreground, bringing Fnordadel to
Once Fnordadel is running in the background, you will probably want to
bring it to the foreground at some point. At the very least, you will
have to do this when you want to shut Fnordadel down, since the only way
to properly take the system down is using the @samp{^LQ} command. To
reconnect Fnordadel to the console, run the utility
@pindex sysop
@code{sysop}, which tells the system to listen up. Fnordadel
will once again display things on your monitor and listen to the keyboard.
See @file{sysop.man}.
To send the system back into the background again, you can hit @samp{^Z}
at the console. Fnordadel will stop displaying to the screen and taking
input from the console keyboard. Make sure you're logged out and the
system is back in modem mode when you do this! @xref{Special keys}, for
more info about @samp{^Z}. Also see @ref{Special net keys}.
@cindex Multitasking lock file
@cindex Lock file
Most Fnordadel utility programs that need to update @file{ctdltabl.sys}, or
other system files, will check for the existence of the @file{citadel.lck}
file that was mentioned briefly in the last section. If the file is present,
the utility will abort, otherwise it will go ahead and do its thing.
@emph{Be warned}, however, that there may be a utility or three that doesn't
behave properly in this regard. Thus if you are running Fnordadel in the
background, be very careful to avoid clobbering something by running Fnordadel
updating utilities at the same time.
@node Fnordadel vs. STadel, Compatibilities, Multitasking and Fnordadel, Miscellaneous
@section Fnordadel vs. STadel
@cindex STadel vs. Fnordadel
This section is for those of you who are converting up from STadel.
If you aren't converting, you can read it for trivia, or ignore it. We have
developed a converter program to take STadel 3.3d systems to the current
version of Fnordadel, hopefully preserving all important system files. See
the @file{conv33d.doc} document for details on conversion.
Since Fnordadel is directly descended from STadel 3.3b, with many
pieces borrowed from STadel 3.4a (which never got released, that we know of),
most of the things you liked about STadel will still be here. We added this
section mainly because many of you who convert will probably notice right
away that some things, such as running @code{configur} or saving messages, seem
slower with Fnordadel. You're not imagining things, and before you get
homicidal or erase Fnordadel from your system, we want to explain.
Some of you may have noticed that the slow-down seems related to room-oriented
operations. If so, you hit the nail on the head. From the conversion
process, you'll know there is a big difference in how rooms are done. This is
what causes the speed difference as well, and is the only aspect in which
Fnordadel is slower than STadel. Hopefully we can temper the shock with
good reasons for the change.
STadel (and other Cits) use a single file to store rooms, called
@file{ctdlroom.sys}. The file is opened once when the system starts, and closed once
when it exits. All rooms occupy a fixed-size record in @file{ctdlroom.sys}, and
accessing the records requires seeking to the record, followed by one read or
write operation to transfer all the room's data.
Some time ago, we got sick and tired of the 58 messages per room limit,
along with all the other limits (64 rooms per system, 16 shared rooms per net
node, etc.) We got rid of them all in a similar fashion to Hue, Jr.'s method
of eliminating the limits in Citadel-86, by allowing the Sysop to define the
limits himself in @file{ctdlcnfg.sys}, and alter them on the fly with various
utility programs. With the messages per room limit, however, we chose a
different approach.
Any fixed number of messages per room, we reasoned, will be inefficient
since there will rarely-approaching-never be exactly that number of messages
in any room. If there are too few messages, the extra space in the room
record will be wasted, while if there are too many messages, they can't all
fit and thus you'll have space in @file{ctdlmsg.sys} wasted by messages that
nobody can ever see.
We therefore decided to make the room records vary in size so they are
always exactly as big as required to fit the number of messages really in each
room. No more wasted space in the room records, and no more wasted space in
the message file. Unfortunately, we could no longer store the room records in
one file, since their varying size would be practically impossible to deal
with in the confines of a single file.
Consequently, we broke the room file up into one file per room, each
now able to be whatever size required to store the number of messages in it.
This gave us the desired space efficiency. It also improved damage control;
with STadel, a bad sector or corrupted room record would wipe out the whole
@file{ctdlroom.sys} file. Since the file can't be regenerated by
@code{configur}, the
effect was to lose your entire message base even though the @file{ctdlmsg.sys} file
was perfectly intact! Now with Fnordadel, a bad sector or corrupted room
record causes the loss of only one room, not the entire message base.
Sadly, the improved space efficiency and security has a price. No
longer do we have the single room file, which is opened once, closed once and
accessed via one read or write operation per room. Now, with one file per
room, each file must be opened and closed each time it is accessed (we can't
have them all open at once; @sc{tos} has limits on this kind of thing). This
opening and closing takes time. Also, we can't use a single read or write to
access the room record, since it varies in size. We first read or write the
fixed-size part of the record (name, status flags, etc.), then the variable-sized
part (message pointers). This double read/write also takes extra time.
The net result is a common one: to improve efficiency, you sacrifice
speed, and vice versa. We're working on ways to get every extra jot of speed
out of the new code, but it will probably always be slower than the older
method. One thing that will help speed it up is to throw the @code{#roomdir}
@vindex roomdir
directory onto a small @sc{ram} disk. If you do this, make sure you back up
the directory to disk regularly, either manually or using a command shell and
automated scripts. If you choose not use the @sc{ram} disk, take some comfort
in knowing that the slower room access times are not for nothing, they are
buying you much increased space efficiency and system reliability.
@node Compatibilities, Beta Releases of Fnordadel, Fnordadel vs. STadel, Miscellaneous
@section Compatibilities, Incompatibilities, and Fixes
This section is for miscellaneous facts we've come across that could
affect your Fnordadel due to other products' behavior.
@itemize @bullet
@item
Turbo ST, a commercial display accelerator, causes the Fnordadel
status line to freak out. We don't know of any version of Turbo
ST that works properly. Our advice is to get ahold of a program
called Quick ST, by Branch Always Software. It's what we use, and
it works great. (@xref{Things to Make Fnordadel Work or Work Better}.)
@item
We've heard a lot of reports about various doors (usually games)
that do not work properly, but we're usually unable to discover
any particular problems since we don't run many doors ourselves.
If you have trouble with a door that is publicly available, the
best approach is to send us a copy of it along with detailed
instructions on how to duplicate your troubles. Then we'll see
if we can fix things. If you can't send us the door for some
reason, send us a detailed description of your problem, and we
might be able to figure out what's going on anyway. If you're
writing your own doors and run into trouble, send us your code
(if you're programming in C), or your executable program (if
you're programming in anything else), and we'll look into it.
@item
As reported by kbad@@Virtuality, Fnordadel appears to work like
a charm on the Atari TT030. So if your ego requires you to have
the hottest Fnordadel this side of Virtuality, run out and buy a
TT for yourself.
@item
So-called ``packer'' programs are popular here and there, especially
with users running without the Amazing Benefits of a hard drive.
These packers compress other executable programs just like archiving
programs such as LHarc, Arc and Zoo. The difference is that the
compressed programs can still be run as before, with the nicety that
they take much less disk space to store. The only cost is that they
take slightly more time to load and execute, since they must
uncompress themselves on the fly.
For users running on floppy drive(s), and finding that space is a
problem, we have two comments. First, space is always a problem,
even with a hard drive. Second, get ahold of a packer
program from your favorite Atari ST file transfer board, and try it
out on the Fnordadel programs and utilities. We don't guarantee
that they will pack, or run properly if packed, but it's worth a try.
@end itemize
@node Beta Releases of Fnordadel, , Compatibilities, Miscellaneous
@section Beta Releases of Fnordadel
@cindex Beta releases of Fnordadel
We put Fnordadel out in ``releases'', rather than small, random
upgrades to different programs. However, the large majority of the
releases are ``beta'', i.e. they have some deficiency, and we don't
necessarily want everybody under the sun to take that version and start
running it. Normally, beta releases are sent to a select few ``beta
sites'', run by Sysops who understand and accept the risks involved with
running beta software that might have problems. They have agreed to
actively help us solve any problems that come up in the code they run,
and we fully expect them to give us detailed bug descriptions (not ``It
doesn't work!''), try out new things we've put in to see if they work,
and give us general feed-back whether we ask for it or not.
Up until now, we have been pretty slack about who gets the beta
releases. We have a small number of beta sites that we deal directly with,
but if other people really want to run the beta versions, they can do so,
providing they can get ahold of them somewhere. Anybody who gives out a
beta release to a non-beta site is expected to clearly communicate that the
software is @emph{not} of public, production quality, and also that the manuals
frequently have not been updated to reflect all changes. We do not make
any kind of guarantees to anybody who runs a beta release that they got
